セッションマネージャーを利用してローカル PC と プライベートサブネットにある EC2 間でデータ転送したときのデータ転送料を調べてみた
疑問
プライベートサブネットにある EC2 へ、セッションマネージャーを越しに SCP や rsync でデータ転送すると費用はいくらかかるのでしょうか？素朴な疑問解消するべく検証した記録です。
検証結果
公式ドキュメントからは判断つかなかったため、データ転送した結果の請求額から判断しています。
- セッションマネージャーを経由させるとAWS からのインターネットアウトの料金は発生しない
- NAT Gateway 経由は NAT Gateway の処理料金のみが発生
- NAT Gateway の起動代は別途発生します
- VPC エンドポイント経由は VPC エンドポイントの処理料金のみが発生
- VPC エンドポイントの起動代は別途発生します
- 価格は東京リージョン（
ap-northeast-1）の2022年7月1日時点の料金を表記しています
2022/7/4追記追加でパブリックサブネットの場合も検証した結果、セッションマネージャー経由は転送速度が遅いことがわかりました。
準備
プラベートサブネットにファイル送受信用の EC2 を起動します。
EC2 インスタンス
c6gd.large のインスタンスストアをファイル転送用のストレージとして利用します。OS は Amazon Linux 2です。
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme1n1 259:0 0 109.9G 0 disk
nvme0n1 259:1 0 8G 0 disk
├─nvme0n1p1 259:2 0 8G 0 part /
└─nvme0n1p128 259:3 0 10M 0 part /boot/efi
$ sudo mkfs -t xfs /dev/nvme1n1
meta-data=/dev/nvme1n1 isize=512 agcount=4, agsize=7202149 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=0
data = bsize=4096 blocks=28808593, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=14066, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
$ sudo mkdir /scratch
$ sudo mount /dev/nvme1n1 /scratch/
$ sudo chown ec2-user. /scratch/
$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 412K 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/nvme0n1p1 8.0G 1.6G 6.5G 20% /
/dev/nvme0n1p128 10M 3.8M 6.3M 38% /boot/efi
tmpfs 382M 0 382M 0% /run/user/0
/dev/nvme1n1 110G 145M 110G 1% /scratch
/scratchディレクトリにインスタンスストアをマウントして準備完了しました。
ファイル転送してみる
ローカル PC で10GB サイズのダミーファイルを作成しました。このファイルを EC2 へアップロード、ダウンロードして課金される対象を CloudWatch のメトリクスと、請求書から確認します。
$ mkfile 10g 10GB.dummy $ ls -lh total 20979848 -rw------- 1 ohmura.yasutaka staff 10G 6 7 18:21 10GB.dummy
NAT Gateway 編
ローカル PC からプラベートサブネットの EC2 へセッションマネージャーで接続する経路は図の状態です。
アップロード
セッションマネージャー + SCP で EC2 インスタンスへファイルをアップロードします。かなり遅いです。
$ scp -i ../../sandbox-key.pem ./10GB.dummy ec2-user@i-04bf3f07dd8155134:/scratch 10GB.dummy 1% 131MB 859.6KB/s 3:20:42 ETA
セッションマネージャー + rsync でも速度は変わりませんね。このまま rsync でファイルのアップロード終わるまで放置します。
$ rsync -ahv --partial --append --progress -e "ssh -i ../../sandbox-key.pem" ./10GB.dummy ec2-user@i-04bf3f07dd8155134:/scratch
building file list ...
1 file to consider
10GB.dummy
18.45M 0% 858.65kB/s 3:28:03
3時間半後には終わっていました。
building file list ...
1 file to consider
10GB.dummy
10.74G 100% 804.73kB/s 3:37:10 (xfer#1, to-check=0/1)
sent 10.70G bytes received 42 bytes 820.79K bytes/sec
total size is 10.74G speedup is 1.00
ダウンロード
EC2 へアップロードしたファイルを今度はダウンロードします。時間かかるのでまた待ちます。
$ rsync -ahv --partial --append --progress -e "ssh -i ../../sandbox-key.pem" ec2-user@i-04bf3f07dd8155134:/scratch/10GB.dummy ./10GB.dummy.down
receiving file list ...
1 file to consider
10GB.dummy
15.56M 0% 916.97kB/s 3:14:52
2時間半で完了しました。
$ rsync -ahv --partial --append --progress -e "ssh -i ../../sandbox-key.pem" ec2-user@i-04bf3f07dd8155134:/scratch/10GB.dummy ./10GB.dummy.down
receiving file list ...
1 file to consider
10GB.dummy
2.32G 21% 915.18kB/s 2:33:22
結果確認
CloudWatch のメトリクスから前半のアップロード、後半のダウンロードのグラフを確認します。
| メトリクス | 説明 |
|---|---|
| BytesInFromSource | VPC 内のクライアントから NAT ゲートウェイによって受信されたバイト数 |
| BytesOutToSource | VPC 内の NAT ゲートウェイ経由でクライアントに送信されたバイト数 |
Amazon CloudWatch による NAT ゲートウェイのモニタリング - Amazon Virtual Private Cloud
オレンジの線はローカル PC から NAT Gateway 経由で EC2（クライアント）へファイルをアップロードしたときのバイト数が確認できます。
青色の線はNAT Gateway 経由で EC2（クライアント）からローカル PC へファイルをダウンロードしたときのバイト数が確認できます。アップロード、ダウンロードともに NAT Gateway を経由していることを確認できました。
翌日、請求書を確認すると10GBファイルのアップロード、ダウンロードで合計20GB の NAT Gateway のデータ処理料が発生してることが確認できます。前日時点でほぼ 0GB 表示のキャプチャを取得しておけばよかったです。
NAT Gateway からローカル PC まではインターネットへ出ているため、インターネットアウトの料金が適用されるかと思ったのですが請求されていません。
NAT ゲートウェイを介して転送されるすべてのデータに対して標準的な AWS データ転送料金が発生します。 料金 - Amazon VPC | AWS
判明したこと
VPC エンドポイント編
ローカル PC からプラベートサブネットの EC2 へセッションマネージャーで接続する経路は図の状態です。請求書のデータアウトの項目が NAT Gateway の経路検証と混在しないよう日を空けて検証を再開しました。
アップロード
セッションマネージャー + rsync で同様にアップロードしました。
$ rsync -ahv --partial --append --progress -e "ssh -i ../../sandbox-key.pem" ./10GB.dummy ec2-user@i-07008295ecdabfa16:/scratch
building file list ...
1 file to consider
10GB.dummy
10.74G 100% 3.25MB/s 0:52:31 (xfer#1, to-check=0/1)
sent 2.61G bytes received 42 bytes 827.24K bytes/sec
total size is 10.74G speedup is 4.11
ダウンロード
同様にアップロードしたファイルをダウンロードしました。
$ rsync -ahv --partial --append --progress -e "ssh -i ../../sandbox-key.pem" ec2-user@i-07008295ecdabfa16:/scratch/10GB.dummy ./10GB.dummy.down
receiving file list ...
1 file to consider
10GB.dummy
10.74G 100% 921.29kB/s 3:09:41 (xfer#1, to-check=0/1)
sent 38 bytes received 10.74G bytes 943.31K bytes/sec
total size is 10.74G speedup is 1.00
結果確認
CloudWatch のメトリクスから前半のアップロード、後半のダウンロードのグラフを確認します。
| メトリクス | 説明 |
|---|---|
| BytesProcessed | エンドポイントとエンドポイントサービスの間で交換されたバイト数 (両方向を集約)。これは、エンドポイントの所有者に料金が請求されるバイト数です。請求書には、この値が GB 単位で表示されます。 |
AWS PrivateLink の CloudWatch メトリクス - Amazon Virtual Private Cloud
アップロード時の各エンドポイントの状況です。グラフが途切れているのはローカル PC のスリープ設定を誤りスリープで中断しました。それでファイル転送の途切れが2度発生しています。レジュームオプションのおかげで再開して転送を終えました。
ダウンロードはスリープ設定を2度もミスった経験を活かし無事スリープにならずに転送を終えました。
アップロード、ダウンロード通してみてみると、ファイル転送で主に利用される VPC エンドポイントはssmmessagesでした。
| エンドポイント名 | 説明 |
|---|---|
| com.amazonaws.region.ssm | Systems Manager サービスのエンドポイント |
| com.amazonaws.region.ec2messages | Systems Manager は、このエンドポイントを使用して、SSM Agent から Systems Manager サービスへの呼び出しを行います。 |
| com.amazonaws.region.ssmmessages | このエンドポイントは、Session Manager を使用して安全なデータチャネルを経由してインスタンスに接続する場合にのみ必要です。 |
ステップ 6: (オプション) Virtual Private Cloud エンドポイントの作成 - AWS Systems Manager
翌日、請求書を確認すると10GBファイルのアップロード、ダウンロードで合計20GB の VPC エンドポイントのデータ処理料が発生していることが確認できます。
Before
After
NAT Gateway の経路と同様に Systems Manager とオンプレ間のインターネットアウトの料金は適用されていません。
Before
After
判明したこと
まとめ
Systems Manager を経由したデータ転送には AWS からのインターネットアウトの料金は発生しませんでした。 NAT Gateway 経由は NAT Gateway の処理料金が、VPC エンドポイント経由は VPC エンドポイントの処理料金が発生します。別途リソースの起動代は発生します。
逆に AWS へアップロード（インターネットから AWS へ）は S3 を経由など費用のかからない経路を利用した方がいいですね。
おわりに
想定と異なった結果だったため、本当にインターネットアウトの料金が発生しないのかあれこれ検証した結果の見どころだけまとめした。
オンプレと Systems Manager 間のセッションマネージャーの主なユースケースはシェルアクセスか、ちょっとしたファイル転送くらいだったため今まで通信経路のコストを意識したことがありませんでした。インターネットのアウト料金は CloudWatch のメトリクスで追えない都合、請求書の料金しか判断できる材料はありませんでした。なにか良い判定方法があればご連絡いただけると嬉しいです。パブリックサブネットにおいた EC2 からの場合、セッションマネージャー経由してファイル転送するとどうなるのかが気になっているので近いうちに検証しようと思います。
2022/7/4追記パブリックサブネット編を検証しました。
一般的な通信経路の最適化では以下のブログが参考になりますので是非チェックしてください。
